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Limited Slow-Start for TCP with Large Congestion Windows 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
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Distribution of this memo is unlimited. 
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Abstract 


This document describes an optional modification for TCP’s slow-start 
for use with TCP connections with large congestion windows. For TCP 
connections that are able to use congestion windows of thousands (or 
tens of thousands) of MSS-sized segments (for MSS the sender’s 
MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in 
increasing the congestion window by thousands of segments in a single 
round-trip time. Such an increase can easily result in thousands of 
packets being dropped in one round-trip time. This is often 
counter-productive for the TCP flow itself, and is also hard on the 
rest of the traffic sharing the congested link. This note describes 
Limited Slow-Start as an optional mechanism for limiting the number 
of segments by which the congestion window is increased for one 
window of data during slow-start, in order to improve performance for 
TCP connections with large congestion windows. 


1. Introduction 


This note describes an optional modification for TCP’s slow-start for 
use with TCP connections with large congestion windows. For TCP 
connections that are able to use congestion windows of thousands (or 
tens of thousands) of MSS-sized segments (for MSS the sender’s 
MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in 
increasing the congestion window by thousands of segments in a single 
round-trip time. Such an increase can easily result in thousands of 
packets being dropped in one round-trip time. This is often 
counter-productive for the TCP flow itself, and is also hard on the 
rest of the traffic sharing the congested link. This note describes 
Limited Slow-Start, limiting the number of segments by which the 
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congestion window is increased for one window of data during slow- 
start, in order to improve performance for TCP connections with large 
congestion windows. 


When slow-start results in a large increase in the congestion window 
in one round-trip time, a large number of packets might be dropped in 
the network (even with carefully-tuned active queue management 
mechanisms in the routers). This drop of a large number of packets 
in the network can result in unnecessary retransmit timeouts for the 
TCP connection. The TCP connection could end up in the congestion 
avoidance phase with a very small congestion window, and could take a 
large number of round-trip times to recover its old congestion 
window. This poor performance is illustrated in [F02]. 


2. The Proposal for Limited Slow-Start 


Limited Slow-Start introduces a parameter, "max_ssthresh", and 
modifies the slow-start mechanism for values of the congestion window 
where "cwnd" is greater than "max_ssthresh". That is, during Slow- 
Start, when 


cwnd <= max_ssthresh, 


cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every 
arriving ACK (acknowledgement) during slow-start, as is always the 
case. During Limited Slow-Start, when 


max_ssthresh < cwnd <= ssthresh, 


the invariant is maintained so that the congestion window is 
increased during slow-start by at most max_ssthresh/2 MSS per round- 
trip time. This is done as follows: 


For each arriving ACK in slow-start: 
If (cwnd <= max_ssthresh) 
cwnd += MSS; 
else 
K = int (cwnd/ (0.5 max_ssthresh) ); 
cwnd += int (MSS/K); 


Thus, during Limited Slow-Start the window is increased by 1/K MSS 
for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead 
of by 1 MSS as in standard slow-start [RFC2581]. 
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When 
ssthresh < cwnd, 


slow-start is exited, and the sender is in the Congestion Avoidance 
phase. 


Our recommendation would be for max_ssthresh to be set to 100 MSS. 
(This is illustrated in the NS [NS] simulator, for snapshots after 
May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and 
",/test-all-tcpHighspeed tcpHighspeed1" in the subdirectory 
"tcl/lib". Setting max_ssthresh to Infinity causes the TCP 
connection in NS not to use Limited Slow-Start.) 


With Limited Slow-Start, when the congestion window is greater than 
max_ssthresh, the window is increased by at most 1/2 MSS for each 
arriving ACK; when the congestion window is greater than 1.5 
max_ssthresh, the window is increased by at most 1/3 MSS for each 
arriving ACK, and so on. 


With Limited Slow-Start it takes: 
log (max_ssthresh) 


round-trip times to reach a congestion window of max_ssthresh, and it 
takes: 


log (max_ssthresh) + (cwnd - max_ssthresh) / (max_ssthresh/2) 


round-trip times to reach a congestion window of cwnd, for a 
congestion window greater than max_ssthresh. 


Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it 
would take 836 round-trip times to reach a congestion window of 
83,000 packets, compared to 16 round-trip times without Limited 
Slow-Start (assuming no packet drops). With Limited Slow-Start, the 
largest transient queue during slow-start would be 100 packets; 
without Limited Slow-Start, the transient queue during Slow-Start 
would reach more than 32,000 packets. 


By limiting the maximum increase in the congestion window in a 
round-trip time, Limited Slow-Start can reduce the number of drops 
during slow-start, and improve the performance of TCP connections 
with large congestion windows. 
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Experimental Results 


Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100 
kernel, and performed experiments comparing TCP with and without 
Limited Slow-Start [D02]. Results so far show improved performance 
for TCPs using Limited Slow-Start. There are also several 
experiments comparing different values for max_ssthresh. 


Related Proposals 


There has been considerable research on mechanisms for the TCP sender 
to learn about the limitations of the available bandwidth, and to 
exit slow-start before receiving a congestion indication from the 
network [VEGAS,H96]. Other proposals set TCP’s slow-start parameter 
ssthresh based on information from previous TCP connections to the 
same destination [WS95,G00]. This document proposes a simple 
limitation on slow-start that can be effective in some cases even in 
the absence of such mechanisms. The max_ssthresh parameter does not 
replace ssthresh, but is an additional parameter. Thus, Limited 
Slow-Start could be used in addition to mechanisms for setting 
ssthresh. 


Rate-based pacing has also been proposed to improve the performance 
of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that 
rate-based pacing could be of significant benefit, and could be used 
in addition to the Limited Slow-Start in this proposal. 


Appropriate Byte Counting [RFC3465] proposes that TCP increase its 
congestion window as a function of the number of bytes acknowledged, 
rather than as a function of the number of ACKs received. 
Appropriate Byte Counting is largely orthogonal to this proposal for 
Limited Slow-Start. 


Limited Slow-Start is also orthogonal to other proposals to change 
mechanisms for exiting slow-start. For example, FACK TCP includes an 
overdamping mechanism to decrease the congestion window somewhat more 
aggressively when a loss occurs during slow-start [MM96]. It is also 
true that larger values for the MSS would reduce the size of the 
congestion window in units of MSS needed to fill a given pipe, and 
therefore would reduce the size of the transient queue in units of 
MSS. 
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